feat: settle a market on an index's rate of change - #1416

Migration 055 made index_change_in_range attestable in #1415. A market on it can be created and attested today and then cannot be settled: parse_attestation_boolean falls past the binary branch to its action_id > 9 guard and returns "unsupported action_id 12".

That is worse than a market waiting. The settlement scheduler matches "unsupported action_id" against permanentSettleErrorSignatures, so it quarantines such a market as a permanent failure instead of retrying it. Both PRs belong in one release for that reason.

The change

IsBinaryAction accepts action 12, so parse_attestation_boolean routes it to parseBinaryActionResult and reads the boolean the action already returns.

func IsBinaryAction(actionID uint16) bool {
	return (actionID >= 6 && actionID <= 9) || actionID == IndexChangeInRangeActionID
}

Membership is explicit rather than a widened bound. Ids 10 and 11, get_high_value and get_low_value, sit between the migration 040 family and action 12. They are numeric, and settlement reads a numeric result as "value > 0 = YES", so a market on either would resolve YES for essentially any price stream. Raising the upper bound to 12 would admit both of them silently, and whether they should ever settle is a product question rather than a side effect of this one.

Nothing else in the node needed to change, and it is worth saying why:

• settle_market never looks at an action id. It calls tn_utils.parse_attestation_boolean and takes the boolean back.
• The encoding side is detected by shape, not by id. EncodeDataPointsABI writes abi.encode(bool) for any single-row, single-boolean result, so request_attestation has been storing action 12's result in exactly the form parseBinaryActionResult expects since feat: attest an index's rate of change at a point in time #1415.
• validate_attestation_date_range already routes id 12.

No migration, and no SQL of any kind.

Tests

tests/streams/order_book/index_change_settlement_test.go carries four end-to-end tests. They are the first markets in this repository to settle through a binary action at all: settlement_test.go settles numeric get_last_record throughout, and binary_actions_test.go calls the binary actions without ever settling one, so parseBinaryActionResult had no end-to-end coverage before this.

Every market in the file settles on the same movement. The stream holds 100.00 one day before the attestation point and 102.00 a minute before it, so the change is exactly 2%.

• A market on [1%, 3%) settles YES and a market on [3%, 5%) settles NO. The NO case earns its place: the action returns FALSE rather than raising, so a market that should resolve NO has to reach settlement rather than fail its attestation.
• The market hash equals the attestation hash for an id-12 market with an open upper tail, so the NULL bound travels through the hash rather than only through the action body. A mismatch here is silent — create_market and request_attestation both succeed and settle_market reports "Attestation not found" from then on.
• Five buckets over one settle time produce exactly one YES. The change lands exactly on the boundary between the third and fourth buckets, which is where the half-open [min, max) rule is asserted: the boundary belongs to the bucket it opens and to no other. Under the inclusive comparison value_in_range uses, both adjacent buckets would resolve YES and a trader holding YES in each would be paid twice.

Two unit tests in extensions/tn_utils/precompiles_test.go pin which ids settle as booleans, covering the 10/11 gap rather than only the members, and check that the constant, the name map and the predicate still agree. Those run in the PR job, which skips tests/streams.

Verification

go test -tags kwiltest ./extensions/tn_utils/ and go test -tags kwiltest ./tests/streams/order_book/, both green locally.

Problem

• resolves: https://github.com/truflation/website/issues/4560

Summary by CodeRabbit

• Bug Fixes

  • Corrected settlement handling for index changes within specified ranges.
  • Ensured binary and numeric action types are interpreted correctly.

• Tests

  • Added coverage for binary action classification and action registry consistency.
  • Added end-to-end validation for order-book settlement across matching, non-matching, open-ended, and boundary ranges.